In software engineering, a 3-tier architecture may be considered a client-server architectural deployment style that utilizes the separation of functionality into layers (or tiers) in which each layer can be located on a physically separate computer. A standard 3-tier architecture may include presentation and application logic in a client tier, application and business logic in a middle tier application server, and data managed by database servers in a 3rd tier. For instance, a user interface may execute on a desktop PC using a standard graphical user interface, while the functional process logic may include separate modules executing on a workstation or application server, and a database system may execute on a database server or mainframe that includes the computer data storage logic.
The middle tier code typically drives 3rd tier data queries, updates, and transactions and implements shared business logic. Data manipulation performed by the application is typically done on object representations of 3rd tier data obtained through data queries (or through other data manipulation APIs or SQL code in the database server).
By separating the application into different layers or tiers, a single layer may be modified or added without having to modifying the entire application. For example, the operating system of the presentation layer may be modified without the necessity of modifying the database layer.
In a typical 3-tier application, such as including a client, an app server and a database, the application logic typically resides on the app server while the application state is typically stored within the database. In order to monitor state changes, developers often have a thread running on the application server that periodically polls the database. The frequency of polling the database may affect the performance of the application. For example, if the database is polled too often, system resources, such as CPU cycles or heap space, may be wasted. On the other hand, if the database is not polled often enough, the system may become sluggish and not be responsive enough.
Prior solutions frequently involve using a single polling frequency based on the business and technical requirements. A major disadvantage of this approach is that the polling frequency does not adapt to varying load situations. A pre-determined polling frequency may work for average load situations, but not may work well in heavy load situations. Another typical approach is to use a notification based mechanism such as a message queue or advanced queue (AQ) where the business logic in the mid-tier may be notified when the application state changes, thereby eliminating the need to poll the database. However, a notification based approach may require significant architecture modifications to, and/or re-writing of, an existing application and can involve a large investment in terms of money and business risk.